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execution  prodines  substantia!  rediHtions  in  overall 
execution  time 

Introduction 

There  are  a  wide  variety  of  prohletiis  that  rei|Uire  geti- 
erating  parallel  execution  plans  F'artial-order  plan¬ 
ners  have  been  widely  viewed  as  an  effective  approach 
to  generating  such  plans.  However,  strictly  spieaking. 
a  partially-ordered  plan  repre.sents  a  set  of  possible 
totally-ordered  plans.  Just  because  two  actions  are 
unordered  relative  to  one  another  doer,  not  imply  tliai 
they  can  be  executed  in  parallel  The  semantics  of 
a  partially-ordered  plan  provide  that  the  two  actions 
can  be  executed  in  either  order.  Simultaneous  execu¬ 
tion  reouires  that  potential  resource  conflicts  between 
unordered  actions  be  made  explicit  and  avoided. 

There  are  numerous  partial-order  planners  presented 
in  the  literature,  including  SIPE  (Wilkins  1984).  NON- 
LIN  (Tate  1976),  SNLP  (McAllester  ic  Rosenblitt  1991), 
UCPOP  (Penberthy  &  Weld  1992),  tweak  (Chapman 
1987),  o-PLAN  (Currie  ir  Tate  1991),  etc.  Many 

*The  research  reported  here  was  supported  by  Roine 
Laboratory  of  the  Air  Force  Systems  Command  and  the 
Advanced  Research  Projects  Agency  under  contract  no 
F30602-91-C-0081 .  The  views  and  conclusions  contained 
in  this  document  are  those  of  the  author  and  should  not  be 
interpreted  as  representing  the  official  policies  of  ARPA, 
RL,  the  U.S.  Government,  or  any  person  or  agency  con¬ 
nected  with  them. 


Ilf  ilii-v.  plaiiiii-rs  ha\i-  been  iiv.  d  ti.  prndiiee  parallel 
plans  but  previously  no  one  has  prerisely  describe') 
the  class  of  parallel  plar.s  tin  y  proii.iif  idenlitieii  lli>  ir 
liniitations  or  describeil  the  assumptions  made  for  i  In 
parallel  plans  shat  tiny  .j..  produce 

lliis  paper  fo' uv-s  ,,n  th>  iiv  of  partial  'uder  plan 
iiiiiK  to  gen-rnte  parallel  exe,  ution  pLans  first  we 
identify  I  he  rondil  ions  uinler  which  iw"  iinor'ierei)  a' 
ti.ins  .  an  be  exeriiied  m  parallel  ]  |i>  coinpoiieni  miss 
ing  from  many  planners  is  an  explicit  repriisruitati'ui 
of  r<-soiiries  ■s.T'uid  assuming  that  the  resoiiri  e  ron 
SI  raint  s  lia\ .  been  m.ade  expli''  il  wi  nlent  ify  i  In  c  lasses 
of  parallel  exe'-iilion  plans  that  can  l>e  generated  using 
different  pariial-onfer  planners  flurd  we  present  an 
mipleiiieiitaltoti  of  a  parallel  exeruiion  planner  baseil 
on  I  (  I’ol’  fourth  we  ifescribe  Ilow  ihts  planner  can 
be  iivd  to  generate  parallel  query  acri's.s  plaits  fifth, 
we  compare  ihe  use  of  a  partial order  planner  to  other 
afqiroaclies  to  buil.bng  par.allel  .'xecution  [dans  Fi¬ 
nally  we  review  the  contributions  of  the  [lajier  and 
desertin'  some  directions  for  future  resf.irrh 

Executing  Actions  in  Parallel 

('lassual  planners  assume  that  the  execution  of  an 
artioii  IS  indivisible  anif  unintprru|>l ible  (Weld  1994) 

1  tiis  is  referred  to  as  the  atomic  action  a.s.sumf>t ion  and 
stems  from  the  fact  that  the  s  I  Rll’s-cityle  rejiresenla- 
tion  only  models  the  preconditions  and  effects  of  an  ac¬ 
tion  This  as.sutnpl ion  would  apjiear  to  make  siiniilta 
neous  execution  impossible,  since  it  is  unclear  from  the 
action  model  whether  any  two  actions  can  be  executed 
simultaneously  without  inteiacting  with  one  another 
This  section  identifies  the  conditions  under  which  it  is 
po8,sible  to  execute  two  actions  in  parallel 

The  work  on  parallelizing  execution  of  machine  in¬ 
structions  (Tjaden  &  Flynn  1970)  provides  sonie  in¬ 
sight  on  the  types  of  dependencies  that  arise  between 
actions.  Tjaden  and  Flynn  identify  three  types  of  de¬ 
pendencies  that  must  be  conridered  in  parallelizing  ma¬ 
chine  instruction.s:  procedural,  operational,  and  data 
A  procedural  df  pt  ndency  occurs  when  one  insi  riicl  mn 
explicitly  addresses  another  in.-itrurtion  and  tlierffore 
imposes  an  ordering  betweeii  the  instructions  .An  op¬ 
erational  dependency  occurs  when  there  is  a  ri-soiirre 
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Abstract 

Many  reaJ-worid  plauninK  probirms  require  Kcnerat- 
ing  plan*  that  maximire  the  parallelism  inherent  in  a 
problem.  There  are  a  number  of  partial-order  plan¬ 
ners  that  generate  such  plans;  however,  in  most  of 
these  planners  it  Is  unclear  under  what  conditions  the 
resulting  plans  will  be  correct  and  whether  the  planner 
can  even  find  a  plan  if  one  exists.  This  paper  identifies 
the  underlying  astumptions  about  when  a  partial  plan 
can  be  executed  in  parjilel.  defines  the  classes  of  par¬ 
allel  plans  that  can  be  generated  by  different  partial- 
order  planners,  and  describes  the  changes  required  to 
turn  iiCTPOF  into  a  parallel  execution  planner.  In  ad¬ 
dition,  we  describe  how  this  planner  can  be  applied  to 
the  problem  of  query  access  planning,  where  parallel 
execution  produces  substantial  reductions  in  overall 
execution  time. 

Introduction 

There  are  a  wide  variety  of  problems  that  require  gen¬ 
erating  parallel  execution  plans.  Partial-order  plan¬ 
ners  have  been  widely  viewed  as  an  effective  approach 
to  generating  such  plans.  However,  strictly  speaking, 
a  partially-ordered  plan  represents  a  set  of  possible 
totally-ordered  plans.  Just  because  two  actions  are 
unordered  relative  to  one  another  does  not  imply  that 
they  can  be  executed  in  parallel.  The  semantics  of 
a  partially-ordered  plan  provide  that  the  two  actions 
can  be  executed  in  either  order.  Simultaneous  execu¬ 
tion  requires  that  potential  resource  conflicts  between 
unordered  actions  be  made  explicit  and  avoided. 

There  are  numerous  partial-order  planners  presented 
in  the  literature,  including  SIPE  (Wilkins  1984),  NON- 
LIN  (Tate  1976),  SNLP  (McAllester  k,  Rosenblitt  1991), 
UCPOP  (Penberthy  k  Weld  1992),  tweak  (Chapman 
1987),  O-PLAN  (Currie  k  Tate  1991),  etc.  Many 
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of  these  planners  have  been  used  to  produce  parallel 
plans,  but  previously  no  one  has  precisely  described 
the  class  of  parallel  plans  they  produce,  idenlified  their 
limitations,  or  described  the  a.ssumptions  made  for  the 
parallel  plans  that  they  do  produce. 

This  paper  focuses  on  the  use  of  partial-order  plan¬ 
ning  to  generate  parallel  execution  plans.  First,  we 
identify  the  conditions  under  which  two  utiordered  ac¬ 
tions  can  be  executed  in  parallel.  The  component  miss¬ 
ing  from  many  planners  is  an  explicit  representation 
of  resources.  Second,  assuming  that  the  resource  con¬ 
straints  have  been  made  explicit,  we  identify  the  clas.ses 
of  parallel  execution  plans  that  can  be  generated  using 
different  partial-order  planners.  Third,  we  present  an 
implementation  of  a  parallel  execution  planner  based 
on  UCPOP.  Fourth,  we  describe  how  this  planner  can 
be  used  to  generate  parallel  query  access  plans.  Fifth, 
we  compare  the  use  of  a  partial-order  planner  to  other 
approaches  to  building  parallel  execution  plans.  Fi¬ 
nally,  we  review  the  contributions  of  the  paper  and 
describe  some  directions  for  future  research. 

Executing  Actions  in  Parallel 

Classical  planners  assume  that  the  execution  of  an 
action  is  indivisible  and  uninterruptible  (Weld  1994). 
This  is  referred  to  as  the  atomic  action  assumption  and 
stems  from  the  fact  that  the  STRlPs-style  representa¬ 
tion  only  models  the  preconditions  and  effects  of  an  ac¬ 
tion.  This  assumption  would  appear  to  make  simulta¬ 
neous  execution  impossible,  since  it  is  unclear  from  the 
action  model  whether  any  two  actions  can  be  executed 
simultaneously  without  interacting  with  one  another. 
This  section  identifies  the  conditions  under  which  it  is 
possible  to  execute  two  actions  in  parallel. 

The  work  on  parallelizing  execution  of  machine  in¬ 
structions  (Tjaden  k  Flynn  1970)  provides  some  in¬ 
sight  on  the  types  of  dependencies  that  arise  between 
actions,  Tjaden  and  Flynn  identify  three  types  of  de¬ 
pendencies  that  must  be  considered  in  parallelizing  ma¬ 
chine  instructions:  procedural,  operational,  and  data. 
A  procedural  dependency  occurs  when  one  instruction 
explicitly  addresses  another  instruction  and  therefore 
imposes  an  ordering  between  the  instructions.  An  op- 
eraiionat  dependency  occurs  when  there  is  a  resource 


associated  with  an  instruction  that  is  potentially  un¬ 
available.  A  data  dependency  occurs  when  one  instruc¬ 
tion  produces  a  result  that  is  used  by  another  instruc¬ 
tion. 

Similar  dependencies  arise  in  the  parallelization  of 
planning  operations.  A  procedural  dependency  arises 
when  one  operation  is  explicitly  ordered  after  another 
operation,  which  occurs  in  many  of  the  hierarchical 
planners  (Tate  1976;  Wilkins  1984)  (e.g.,  see  the  plot 
construct  in  SIPE).  This  type  of  constraint  is  cap¬ 
tured  by  explicit  ordering  constraints  between  actions. 
A  data  dependency  arises  when  the  precondition  of 
one  operation  depends  on  the  effects  of  another  op¬ 
eration.  This  type  of  dependency  is  captured  by  the 
operator  representation  and  corresponding  algorithms, 
which  ensure  that  if  two  actions  are  unordered  rela¬ 
tive  to  one  another,  their  preconditions  and  effects  are 
consistent.  Operational  dependencies  can  occur  when 
there  are  limited  resources  associated  with  an  oper- 
Jttion.  This  type  of  dependency  is  often  ignored  by 
planning  systems. 

Executing  actions  in  parallel  requires  explicit  han¬ 
dling  of  potential  resource  conflicts.  If  two  actions  are 
left  unordered  in  a  partial-order  plan,  they  can  be  ex¬ 
ecuted  in  either  order.  In  order  to  execute  them  in 
parallel,  we  must  ensure  that  there  are  no  potential 
conflict.s  that  occur  during  execution.  Most  conflicts 
will  be  resolved  in  the  process  of  ensuring  that  the 
preconditions  and  effects  are  consistent.  However,  be¬ 
cause  of  the  limited  representation,  the  type  of  conflict 
that  is  not  typically  handled  in  a  partial-order  planner 
is  when  two  actions  require  the  same  reusable  resource. 
This  type  of  resource  conflict  is  not  typically  captured 
by  the  preconditions  and  eft'ects  because  at  the  start  of 
execution  the  resource  is  available  and  when  execution 
completes  it  is  available. 

Despite  the  problem  of  potential  resource  conflicts,  a 
number  of  partial-order  planners  have  allowed  simulta¬ 
neous  execution.  They  do  so  by  either  a.ssuming  the  ac¬ 
tions  are  independent  (Tate  1976),  augmenting  the  ac¬ 
tion  representation  to  avoid  resource  conflicts  (Wilkins 
1984),  or  requiring  the  user  to  explicitly  represent  the 
conflicts  in  the  preconditions  and  effects  of  the  opera¬ 
tors  (Currie  k  Tate  1991).  The  approach  of  simply  as¬ 
suming  that  the  actions  are  independent  could  lead  to 
unexpected  resource  conflicts.  The  approach  of  requir¬ 
ing  the  user  to  represent  the  conflicts  in  the  precondi¬ 
tions  and  effects  is  both  awkward  and  computationally 
more  expensive,  since  it  requires  additional  operators 
that  explicitly  allocate  and  deallocate  resources.  The 
most  natural  approach  is  to  augment  the  action  rep¬ 
resentation  to  describe  the  explicit  resource  needs  of 
the  different  actions.  This  approach  was  proposed  in 
SIPE  (Wilkins  1984),  where  each  operator  can  be  anno¬ 
tated  to  explicitly  state  if  something  is  a  resource.  In 
the  next  section  we  will  assume  that  the  resource  con¬ 
straints  have  been  made  explicit  and  in  the  following 
section  we  will  describe  our  approach  to  representing 
and  reasoning  about  resources. 


Parallel  Execution  Plans 

This  section  identifies  the  classes  of  parallel  execution 
plans  that  can  be  generated  by  different  planners,  as¬ 
suming  that  a  domain  is  correctly  axiomatized  and 
explicitly  represents  the  resource  requirements  of  the 
operators.  The  different  types  of  parallel  execution 
plans  can  be  broken  down  into  several  classes,  rang¬ 
ing  from  plans  with  completely  independent  actions  to 
those  where  the  actions  must  be  executed  in  parallel 
or  must  overlap  in  a  particular  manner  in  order  for 
the  plan  to  succeed.  As  the  interactions  in  the  plan 
increase  in  complexity,  the  corresponding  planners  re¬ 
quire  more  sophisticated  representations  and  reason¬ 
ing  in  order  to  generate  such  plans.  In  this  section 
we  present  four  classes  of  parallel  execution  plans  and 
identify  the  corresponding  planners  that  can  generate 
that  class  of  plans.  These  classes  are  described  in  order 
from  the  most  restrictive  to  the  least  restrictive. 

Independent  Actions 

The  most  restricted  type  of  parallel  execution  plans  arc 
those  where  all  of  the  parallel  actions  are  completely 
ip-iopendent  of  one  another. 

Two  actions  are  defined  to  be  independent  if  and 
only  if  the  effects  of  the  two  actions  executed 
simultaneously  arc  the  union  of  the  individual 
effects  of  the  actions  done  in  isolation. 

Allen  (1991)  notes  that  various  partial-order  plan¬ 
ners,  such  as  NONLIN  (Tate  1976).  deviser  (Vere 
1983),  and  SIPE  (Wilkins  1984),  all  “allow  simultane¬ 
ous  action  when  the  two  actions  are  completely  inde¬ 
pendent  of  each  other.”  While  this  statement  is  cor¬ 
rect.  it  is  a  bit  misleading  since  these  planners  can 
generate  plans  for  a  less  restrictive  class  of  parallel 
plans.  As  noted  by  Ilorz  (1993),  since  some  of  the 
effects  of  an  operator  may  be  unnecessary  with  respect 
to  the  goal  and  preconditions  of  other  operators,  the 
fact  that  two  operators  are  unordered  in  a  plan  gen¬ 
erated  by  a  partial-order  planner  does  not  imply  that 
the)’  are  independent  A  planner  that  can  only  gen¬ 
erate  plans  with  independent  actions  is  t'A  (Minton. 
Bresina,  i:  Drummond  1991).  which  imposes  ordering 
constraints  between  any  pair  of  unordered  actions  that 
could  possibly  interact. 

Figure  1  illustrates  a  simple  plan  with  two  indepen¬ 
dent  actions.  The  goal  of  the  plan  is  to  have  the  table 
painted  red  and  the  chair,  painted  blue.  Since  the  ac¬ 
tions  of  painting  the  table  and  painting  the  chair  are 
independent,  they  can  be  executed  in  parallel. 

Independent  Actions  Relative  to  a  Goal 

in  a  variety  of  partial-order  planners,  such  as  siPE 
(Wilkins  1984),  SNLP  (McAllester  k.  Rosenblitt  1991), 
and  UCPOP  (Penberthy  k.  Weld  1992),  the  planners 
enforce  the  property  that  two  actions  can  only  remain 
unordered  if  there  is  no  threat  between  them  A  threat 
occurs  when  an  operator  could  potentially  delete  a  con- 
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Figure  1:  Plan  With  Independent  Actions 


dition  that  is  relevant  to  achieving  the  final  goal.'  A 
condition  is  defined  to  be  rtlevani  if  and  only  if  it  is 
a  goal  condition  or  a  precondition  of  an  operator  that 
in  turn  achieves  a  relevant  condition.  The  c'ass  of  par¬ 
allel  plans  produced  by  these  planners  are  those  with 
independent  actions  relative  to  the  goal. 

Two  actions  are  independent  relative  to  a  goal G  if 
and  only  if,  for  all  conditions  that  are  relevant 
to  achieving  G,  the  result  of  executing  the  ac¬ 
tions  in  either  order  is  identical  to  the  result 
of  executing  the  actions  simultaneously. 

These  planners  arc  limited  to  this  class  of  plans  since,  if 
there  is  a  threat  between  any  pair  of  actions,  additional 
constraints  are  imposed  on  the  plan  to  eliminate  the 
threat. 

Figure  2  shows  an  example  plan  where  all  of  the 
actions  arc  independent  relative  to  the  goal.  This  ex¬ 
ample  differs  from  the  independent  action  example  in 
that  the  two  painting  actions  each  have  a  side-effect 
of  painting  the  floor  as  well  as  the  object.  Thus,  the 
paint  table  and  paint  chair  operators  are  not  indepen¬ 
dent  since  both  operations  also  paint  the  floor  different 
colors.  However,  since  the  color  of  the  floor  is  irrele¬ 
vant  to  the  goal  of  getting  the  table  painted  red  and 
the  chair  painted  blue,  the  plan  is  still  valid  and  could 
be  generated  by  planners  in  this  class. 
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Figure  2:  Plan  with  Independent  Actions  Relative  to 
the  Goal 


'Some  planners,  such  aa  SNLP  and  earlier  veraiona  of 
UCPOP,  defined  a  threat  to  include  an  operator  that  artil.i 
or  deletes  a  relevant  condition.  This  stronger  definition  of 
a  threat  is  used  to  constrain  the  search  space  and  would 
prevent  some  possible  parallel  plans  from  being  generated. 


Independent  Subplans  Relative  to  a  Goal 

Not  all  partial-order  planners  enforce  the  property  that 
two  actions  can  remain  unordered  only  if  there  are  no 
threats  between  them.  In  particular,  those  planners 
that  implement  some  form  of  Chapman’s  white  knight 
(Chapman  1987)  require  only  that  there  exist  some  op¬ 
erator  that  establishes  a  given  precondition,  but  do  not 
commit  to  which  operator.  More  specificaily,  the  white 
knight  operation  allows  plans  with  the  following  condi¬ 
tions:  There  exists  some  operator  opi  that  achieves  a 
goal  or  precondition  g.  There  exists  a  second  operator 
op-2  that  possibly  deletes  g.  And  there  exists  a  third 
operator  op.3  that  follows  opj  and  achieves  g.  If  we  are 
interested  in  producing  totally-ordered  plans,  then  the 
white  knight  operator  is  not  required  for  completeness. 
However,  the  use  of  the  white  knight  operator  allows 
a  planner  to  generate  a  slightly  more  general  class  of 
parallel  plans. 

The  planners  in  this  class  include  tweak  (Chapman 
1987),  NONLIN  (Tate  1976),  o-plan  (Currie  i:  Tate 
1991),  MP,  and  MPl  (Kambhampali  199'!).  The  class 
of  parallel  plans  produced  by  these  planners  arc  those 
with  independent  subplans  relative  to  a  goat. 

Two  subplans  are  independent  relative  to  a  goaIG 
if  and  only  if.  for  all  conditions  that  are  relc-  . 
vanl  to  achieving  G.  the  result  of  executing  the 
subplans  in  either  order  is  identical  to  the  re¬ 
sult  of  executing  the  subplans  simultaneously. 

The  class  of  parallel  plans  that  can  be  generated  by 
the  planners  in  this  class,  but  cannot  be  generated  by 
the  planners  in  the  previous  class  are  those  where  there 
are  actions  that  are  not  independent,  but  the  subplans 
'"i  which  the  actions  occur  arc  independent. 

Figure  3  shows  an  example  plan  with  independent 
subplans  relative  to  the  goal  (adapted  from  an  exam¬ 
ple  in  (Kambhampati  1994)).  In  this  example,  before 
the  table  and  chair  can  be  painted  red,  they  must  be 
primed,  and  priming  them  has  a  side  effect  of  painting 
the  floor  white.  The  final  goal  of  the  problem  is  to  get 
the  table,  chair,  and  floor  all  painted  red.  Notice  that 
the  action  of  priming  the  chair  interacts  with  paint¬ 
ing  the  table,  since  they  both  change  the  color  of  the 
floor.  Similarly,  priming  the  table  interacts  wiih  paint¬ 
ing  the  chair  Despite  these  potential  interactions,  the 
floor  will  st  il  be  painted  red  at  the  end  of  the  plan 
since  the  table  and  chair  must  be  painted  after  they 
are  primed.  Solving  this  problem  requires  the  white 
knight  operation  to  produce  the  parallel  plan  since  the 
plan  does  not  state  which  painting  operation  will  be 
used  to  achieve  the  final  goal  of  making  the  floor  red. 

The  implementation  of  the  white  knight,  which  al¬ 
lows  a  planner  to  generate  this  more  general  class  of 
parallel  plans,  also  makes  it  difficult  to  extend  the  op¬ 
erator  language  to  efficiently  handle  more  express'V! 
ronstnicts,  such  as  conditional  effects  and  universal 
quantification  (Chapman  1987).  These  more  expres¬ 
sive  language  constructs  are  often  required  for  repre¬ 
senting  and  solving  real  problems. 
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Figure  3:  Plan  with  Independent  Subplans  Relative  to  the  Goal 


Interacting  Actions 

The  most  genersil  class  of  parallel  plans  are  those  where 
the  parallel  actions  interact  in  some  way.  Two  ac¬ 
tions  may  need  to  be  executed  in  parallel  or  two  ac¬ 
tions  may  need  to  overlap  in  a  particular  manner  in 
order  for  the  plan  to  succeed.  For  example,  if  the  fi¬ 
nal  goal  was  to  get  the  chair  blue,  the  table  yellow, 
and  the  floor  green  and  there  was  no  green  paint,  we 
could  paint  the  table  and  chair  simultaneously.  To 
handle  these  cases  requires  the  introduction  of  an  ex¬ 
plicit  representation  of  time,  such  as  that  provided 
in  temporal  planning  systems  (Allen  ei  al.  1991; 
Penberthy  1993).  However,  in  this  paper  we  are  in¬ 
terested  in  the  more  restricted  case  where  we  would 
like  to  execute  actions  in  parallel  to  take  advantage  of 
the  possible  parallelism  to  reduce  the  total  execution 
time,  not  becai  se  the  solution  requires  parallelism  to 
solve  the  problem. 

Parallel  Execution  Planning  in  UCPOP 

We  used  the  UCPOP  planner  (Penberthy  ii  Weld  1992; 
Barrett  rt  al.  1993)  to  build  a  parallel  execution  plan¬ 
ner.  The  analysis  in  the  previous  section  showed  that 
UCPOP  can  produce  the  class  of  plans  with  actions  that 
are  independent  relative  to  a  goal.  For  the  specific  ap¬ 
plication  described  in  the  next  section,  this  restriction 
does  not  prevent  the  system  from  finding  any  solutions. 
The  changes  to  UCPOP  that  were  required  were  to  add 
explicit  resource  definitions  to  the  operators,  to  modify 
the  planner  to  enforce  the  resource  constraints,  and  to 
construct  an  evaluation  functions  to  estimate  the  cost 
of  the  parallel  plans. 

The  resource  requirements  tF  the  operators  are  made 
explicit  by  augmenting  each  operator  with  a  resource 
declaration.  An  example  operator  with  a  resource  dec¬ 
laration  is  shown  in  Figure  4.  Thii.  operator  describes 
the  action  of  moving  data  from  oiie  data  source  to 
another  and  declares  the  data  source  from  which  the 
data  is  beins;  moved  as  a  resource.  The  purpose  of  this 
declaration  is  to  prevent  one  operator  from  being  ex¬ 
ecuted  in  paral!-l  with  another  operator  that  requinrs 
the  same  database 

In  order  to  avoid  resource  conflicts,  we  modified  the 
planner  to  ensure  th.'>t  if  two  operators  require  the 
same  resource,  then  they  are  not  left  unordered  rel¬ 
ative  to  one  another.  In  SIPE  this  is  done  with  a  critic 


(define  (operator  *ove-data) 

;paraaeters  (?dbl  ?db2  ?data) 

: resources  ((resource  ?dbl  database)) 
:precondition  (:and  (available  ?dbl  ?data) 
(:neq  ?dbl  ?db2)) 

:effect  (rand  (rnot  (available  ?dbl  ?data)) 
(available  ?db2  ?data))) 

Figure  4:  Operator  with  Resource  Declaration 


that  checks  for  resource  conflicts  and  then  imposes  or¬ 
dering  constraints  when  conflicts  are  found.  In  UCPOP, 
we  added  a  check  to  the  planner  such  that  every  time 
a  new  action  is  added  to  the  plan,  the  planner  checks 
for  potential  resource  conflicts  with  any  other  operator 
that  could  be  executed  in  parallel.  Any  conflicts  dis¬ 
covered  are  added  to  the  list  of  threats  that  must  be 
removed  before  the  plan  is  considered  complete.  Using 
the  search  control  facility  in  UCPOP,  these  conflict.?  can 
be  resolved  immediately  or  delayed  until  later  in  the 
planning  process. 

Since  efficiency  is  the  primary  motivation  for  gen¬ 
erating  parallel  plans,  we  constructed  an  evaluation 
function  that  can  be  used  to  find  plans  with  low  over¬ 
all  execution  time.  Since  this  evaluation  function  un¬ 
derestimates  the  cost  of  the  parallel  plan,  the  planner 
can  use  a  best-first  search  to  find  the  optimal  plan. 
This  evaluation  function  takes  into  account  that  the 
cost  of  executing  two  actions  in  parallel  will  be  the 
maximum  and  not  the  sum  of  the  costs.  The  space  of 
parallel  execution  plans  may  be  quite  large,  so  domain- 
specific  control  knowledge  may  be  necessary  to  search 
this  space  efficiently. 

The  evaluation  function  to  determine  the  execution 
time  of  a  parallel  execution  plan  is  implemented  using 
a  depth-first  search.  The  search  starts  at  the  goal  node 
and  recursively  assigns  a  cost  to  each  node  in  the  plan. 
This  cost  represents  the  total  cost  of  execution  up  to 
and  including  the  action  at  the  given  node.  The  cost 
is  calculated  by  adding  the  cost  of  the  action  at  the 
node  to  the  maximum  «.ost  of  all  the  immediately  prior 
nodes.  Once  the  cost  of  the  plan  up  to  u  node  has  been 
computed,  we  store  this  value  so  it  will  only  need  to 
be  calculated  once.  Since  each  nod'’  (n)  and  each  edge 
(e)  in  the  graph  is  visited  only  once,  the  complexity  of 
evaluating  the  plan  cost  is  0(max(n,e)). 


Figure  5:  Parallel  Query  Access  Plan 


Parallel  Query  Access  Plans 

There  are  two  general  characteristics  of  a  domain 
where  the  use  of  a  partial-order  parallel-execution 
planner  will  be  useful  and  effective.  First,  it  is  ap¬ 
plicable  to  those  domains  where  the  actions  could  be 
executed  serially,  but  the  overall  execution  time  can 
be  reduced  by  executing  some  of  the  actions  In  par¬ 
allel.  Second,  it  will  be  most  useful  in  those  domains 
where  the  choice  of  the  operations  determines  or  limits 
the  overall  execution  time  of  the  plan.  As  such,  the 
plan  generation  and  scheduling  cannot  be  done  inde¬ 
pendently  since  this  would  potentially  result  in  highly 
suboptimal  plans. 

We  applied  the  parallel  execution  planner  to  a  query 
access  planning  problem  that  involves  multiple  dis¬ 
tributed  information  sources  (Knoblock  &  Arens  1994). 
In  this  domain,  a  plan  is  produced  that  specifies  how 
to  retrieve  and  generate  the  requested  set  of  data.  This 
requires  selecting  sources  for  the  data,  determining 
what  operations  need  to  be  performed  on  the  data, 
and  deciding  on  the  order  in  which  to  execute  the  op¬ 
erations.  The  planner  must  take  into  account  the  cost 
of  accessing  the  different  information  sources,  the  cost 
of  retrieving  intermediate  results,  and  Ih-  cost  of  com¬ 
bining  these  intermediate  results  to  produce  the  final 
results.  A  partial-order  parallel-execution  planner  is 
ideally  suited  for  this  problem  since  the  parallelization 
is  for  efficiency  purposes,  and  there  are  many  possible 
plans  for  retrieving  the  same  data  and  the  choice  of 
plans  is  crucial  in  determining  the  overall  efficiency. 

Figure  5  shows  an  example  parallel  query-access 
plan.  The  three  basic  query  access  planning  opera¬ 
tions  used  in  this  plan  are  ntove-daia,  join,  and  rc- 
tneve.  The  move-data  operation  moves  a  set  of  data 
from  one  information  source  to  another.  The  join  op¬ 
eration  combines  two  sets  of  data  into  a  combined  set 
using  the  given  join  relations.  The  rrineve  operation 
specifies  the  data  that  is  to  be  retrieved  from  a  partic¬ 
ular  information  source. 

The  domain  and  planner  described  here  are  fully  im¬ 
plemented  and  serve  as  an  integral  part  of  an  informa¬ 
tion  retrieval  agent.  We  have  also  extended  UCI’OP  to 


perform  c.xecution,  and  to  do  so  in  parallel.  The  sys¬ 
tem  is  implemented  and  runs  in  Lucid  Common  Lisp  on 
SUN  and  HP  workstations.  To  provide  a  sense  for  the 
potential  speed-up  of  this  approach  we  ran  a  sample 
query  that  involved  queries  to  two  different  databases. 
Without  parallelization,  the  system  generated  a  plan 
with  six  operators  in  0.82  CPU  seconds  and  then  exe¬ 
cuted  the  plan  in  101.8  seconds  of  elapsed  time.  With 
parallelization,  it  generated  the  plan  in  1.3  CPU  sec¬ 
onds  and  executed  the  plan  in  62.4  seconds  of  elapsed 
time,  a  39  percent  reduction  in  execution  time. 

Related  Work 

An  alternative  approach  to  addressing  the  problem  of 
simultaneous  execution  is  provided  by  work  on  tempo¬ 
ral  planning  (Allen  et  al.  1991;  Penberthy  1993).  A 
temporal  planner  can  handle  the  general  problem  of 
simultaneous  parallel  execution,  but  this  general  solu¬ 
tion  has  a  cost,  since  just  testing  the  satisfiability  of 
a  set  of  assertions  is  NP-hard  (V'ilain,  Kautz,  k  van 
Seek  1989).  The  capabilities  of  a  full-fledged  tempo¬ 
ral  planner  are  neces.sary  only  if  we  need  to  explic¬ 
itly  reason  about  the  interaction  between  parallel  ac¬ 
tions.  In  this  paper  we  focus  on  the  simpler  problem 
of  non-interacting  simultaneous  execution,  which  does 
not  require  a  full-blown  temporal  reasoner  to  handle. 
In  fact,  partial-order  planners  appear  to  be  well  suited 
for  problems  in  this  class. 

Another  approach  to  this  problem  is  to  generate 
totally-ordered  plans  and  then  convert  each  plan  into 
a  partially-ordered  plan  (Veloso,  Perez,  k  Carbonell 
1990;  Regnier  k  Fade  1991).  The  problem  with  this 
approach  is  that  the  particular  choice  of  the  totally- 
ordered  plan  determines  the  parallel  execution  plan. 
As  such,  in  order  to  consider  the  space  of  parallel  ex¬ 
ecution  plans  requires  searching  through  the  space  of 
totally-ordered  plans.  Since  a  single  partially-ordered 
plan  often  corresponds  to  a  number  of  totally-ordered 
plans,  it  will  be  harder  to  efficiently  search  the  space 
of  parallel  execution  plans. 

Recently,  Backstrom  (1993)  showed  that  the  general 
problem  of  finding  an  optimal  parallel  execution  plan 
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is  NP-hard.  We  cannot  escape  from  this  complexity  re¬ 
sult;  however,  partial-order  planners  do  avoid  the  NP- 
hard  subproblem  of  testing  satisfiability  and  provide 
a  more  natural  framework  than  total-order  planners 
for  sewching  the  space  of  parallel  plans  and  encoding 
domain-specific  control  knowledge  to  guide  the  search. 

Discussion 

The  idea  of  using  partial-order  planning  to  generate 
parallel  execution  plans  has  been  around  since  the  early 
days  of  planning.  What  we  have  done  in  this  paper  is 
to  explicate  the  underlying  assumptions  and  situations 
where  parallel  execution  is  possible,  characterize  the 
differences  in  the  plans  produced  by  various  planning 
algorithms,  and  identify  the  changes  required  to  use 
UCPOP  as  a  parallel  execution  planner.  We  have  also 
shown  that  these  ideas  apply  directly  to  the  problem 
of  generating  parallel  query  access  plans. 

In  future  work  we  plan  to  tightly  integrate  the  plan¬ 
ning  and  execution  components.  This  would  allow  the 
system  to  dynamically  replan  actions  that  fail,  while 
continuing  to  execute  other  actions  that  are  already 
in  progress.  In  addition,  we  plan  explore  the  problem 
of  how  to  efficiently  search  the  space  of  parallel  execu¬ 
tion  plans.  First,  we  will  consider  domain-independent 
search  strategies  that  produce  the  highest  quality  so¬ 
lution  that  can  be  found  within  the  time  allotted.  Sec¬ 
ond,  we  will  exploit  domain-specific  knowledge  to  both 
restrict  the  search  space  and  guide  the  search. 
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